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(54) Multi-venue ticketing using smart cards 

(57) A system and methods are provided for storing 
and validating electronic tickets for multiple venues on a 
single smart card. In accordance with this present 
embodiment, an operating system of the smart card 
includes a Java Virtual Machine and an applet loader 
key. A shared applet (202), including a venue loader key 
(202a), is validated with the applet loader key (200a) 
and is stored on the smart card (100). One or more 
venue applets (210, 220) are also stored on the smart 
card, each with a venue key (210a, 220a) correspond- 
ing to an associated venue. Each venue applet(210, 
220) is validated by the applet loader key (200a) and the 
venue loader key (202a). The shared applet (202) is 
used by the venue applets to interface with ticket load- 
ers (104) and ticket validation devices (106). Tickets 
(212, 214, 216, 222) are purchased for events associ- 
ated with the venue applets and are stored on the smart 
card in association with the related venue applets. 
Ticket signatures (212a, 214a, 216a, 222a) are authen- 
ticated with each venue applet's venue key. A ticket is 
cancelled (516) after being tendered to gain admittance 
to an event. 
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Description 
Background 

[0001] This invention relates to the field of electronic s 
commerce. More particularly, a system and methods 
are provided for electronic ticketing. 
[0002] The use of tickets for sporting venues, enter- 
tainment events, travel and the like is no longer strictly a 
mechanical function. Ticketing systems have evolved to io 
make use of computer systems in various phases of the 
ticket generation, issuance and validation processes. 
[0003] For example, in U.S. Patent No. 5,598,477, 
issued to Berson, a customer submits information con- 
cerning a desired ticket (e.g., scheduling data pertain- is 
ing to an airline flight). A data processing system sends 
ticketing information and encrypted validation data to a 
local printing system. The local system prints the ticket, 
which includes the validating information encoded in a 
two-dimensional barcode. The customer presents the 20 
ticket at flight time, where a validating system scans the 
barcode, transforms the data from physical form into 
digital form and validates it. If valid, the customer 
receives his boarding pass, luggage claim checks, etc. 
[0004] Berson, however, still requires the issuance of 25 
a paper ticket. Paper tickets are, of course, subject to 
theft, mutilation, destruction, loss, etc. In addition, a 
ticket produced according to the Berson system is nec- 
essarily good for only one-time use. The ticket is physi- 
cally collected at the time of the flight. Two additional 30 
disadvantages exist with this scheme. First, the use of 
two-dimensional barcodes requires printers capable of 
producing, and barcode scanners capable of reading, 
such barcodes. Depending upon the number of sites at 
which tickets are printed or accepted, this may involve 35 
significant cost. Second, the use of cryptographic 
means to secure the validation information requires a 
sophisticated key management scheme. 
[0005] In a modification of the Berson system, large 
random numbers may be used in place of cryptographic 40 
security A particular random number is chosen and 
printed as a one-dimensional barcode on a physical 
ticket. The use of large numbers significantly decreases 
the chance of a person correctly guessing the number 
assigned to a particular ticket for a discrete event (e.g., 45 
airplane flight, entertainment event). The random num- 
bers are stored in a database accessible to sites at 
which the tickets are used. When the ticket is presented 
at a site, the number on the ticket is compared to the list 
of valid numbers stored in the database. This scheme so 
still possesses the disadvantages inherent in paper tick- 
ets, such as destruction or mutilation and the limitation 
to a single use. In addition, without further protection, 
the database of random numbers provides a single 
point of vulnerability A person with access to the data- ss 
base could conceivably generate large quantities of 
bogus tickets. 

[0006] In addition to the above disadvantages, known 



ticketing systems provide admission to only a single 
event or a single site. Also, a paper ticket issued by a 
known system is not generally modifiable without physi- 
cally replacing the issued ticket. In other words, a per- 
son who wishes to visit or enjoy multiple events or 
multiple venues must carry and present a different ticket 
for each event or venue. As he or she makes plans to 
visit even more events or venues, additional paper tick- 
ets must be purchased and carried, thus increasing the 
risk of loss. 

Summary 

[0007] In one embodiment of the invention, a system 
and methods are provided for storing, on a single elec- 
tronic device (e.g., smart card, hand-held computer), 
electronic tickets to events offered at multiple venues. In 
this embodiment, the electronic device receives and 
stores a venue module associated with each venue for 
which a ticket is purchased. The venue module enables 
the electronic device to store tickets for the associated 
venue, and includes a venue key for validating individual 
tickets. The electronic device also receives and stores a 
shared ticketing module containing instructions to be 
called by one or more venue modules. The shared tick- 
eting module includes a "venue loader key" for validat- 
ing installed venue modules. 

[0008] After the electronic device is configured with 
the shared ticketing module and one or more venue 
modules, tickets for each installed venue module may 
be stored. In a present embodiment of the invention, the 
electronic device's user identifies parameters (e.g., 
event, date, time, seat) for a ticket and the correspond- 
ing electronic ticket is downloaded from a ticket loader, 
along with a ticket signature. The venue module for the 
corresponding venue module authenticates each stored 
ticket's signature using its venue key. 
[0009] When a ticket is to be presented for admission 
to an event, in a present embodiment a validation device 
challenges the electronic device by issuing a challenge 
code. The venue module for the event's venue signs the 
code with its venue key and returns the signed code. 
After the signature is validated, the electronic device 
transmits the ticket for the event and the ticket is can- 
celed. 

Brief Description of the Figure 
[0010] 

FIG. 1 is a block diagram depicting one system in 
which a smart card is used to store venue applets 
and tickets for admission to a venue in accordance 
with an embodiment of the present invention. 
FIG. 2 depicts a smart card populated with multiple 
venue applets and tickets in accordance with an 
embodiment of the present invention. 
FIG. 3 is a flow chart demonstrating one method of 
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loading a venue applet onto a smart card in accord- 
ance with an embodiment of the present invention. 
FIG. 4 is a flow chart demonstrating one method of 
loading a ticket onto a smart card in accordance 
with an embodiment of the present invention. 
FIG. 5 is a flow chart demonstrating one method of 
validating a ticket stored on a smart card in accord- 
ance with an embodiment of the present invention. 

Detailed Description 

[001 1] The following description is presented to ena- 
ble any person skilled in the art to make and use the 
invention, and is provided in the context of a particular 
application and its requirements. The present invention 
is not intended to be limited to the embodiments shown, 
but is to be accorded the widest scope consistent with 
the principles and features disclosed herein. 
[0012] For example, in a present embodiment of the 
invention, cryptographic means are applied to ensure 
the security of electronic tickets and venue modules, or 
applets (e.g., small Java applications), that are loaded 
onto smart cards. One skilled in the art will recognize 
that the purpose of the cryptographic keys described 
below is to ensure the security and authenticity of infor- 
mation stored on a smart card, and does not necessar- 
ily rely upon a particular cryptographic scheme unless 
otherwise indicated. Various cryptographic keys are 
therefore described below for various purposes. The 
invention is not limited to a particular method of crypto- 
graphic security, however, and specific embodiments of 
the invention may use an asymmetric key scheme, a 
symmetric key scheme, or some other scheme as may 
be devised. 

[0013] In accordance with one embodiment of the 
invention, a system and methods are provided for gen- 
erating, storing and validating electronic tickets for mul- 
tiple venues. The tickets are illustratively stored on a 
standard smart card, although other devices are also 
contemplated such as the PalmPilot by 3COM Corpora- 
tion or the iButton by Dallas Semiconductor. The stored 
tickets may be for any occasions for which admission or 
passage may be pre-purchased, such as sporting 
events, entertainment events, airline flights, automobile 
tolls, etc. Each venue for which a ticket has been stored 
on a smart card in accordance with a present embodi- 
ment of the invention has an associated applet stored 
on the smart card. A shared ticketing applet is also 
stored. These applets are used, as described below, to 
interface between the smart card and ticket/venue load- 
ing facilities and between the smart card and ticket vali- 
dation devices. 

[0014] FIG. 1 depicts an illustrative system for issuing, 
storing and validating tickets stored on a user's smart 
card in an embodiment of the invention. Smart card 100 
illustratively complies with the ISO 7816 specif ication for 
smart cards. As such, it is capable of storing various 
types and amounts of electronic data for later retrieval. 



[0015] Applet loader 102 loads one or more applets 
onto smart card 100. The applets that are loaded onto 
smart card 100 by applet loader 102 enable smart card 
100 to store tickets to venues associated with the 

5 loaded applets. For example, one venue applet may 
correspond to baseball games hosted by the San Fran- 
cisco Giants. Loading this applet enables smart card 
100 to store tickets for specific games or a range of 
games (e.g., a season pass). Illustratively, applet loader 

w 102 is configured to load an applet pertaining to a single 
venue. In an alternative embodiment, however, applet 
loader 1 02 loads applets from multiple venues. 
[001 6] In addition to venue applets (i.e., applets asso- 
ciated with individual venues), a shared ticketing applet 

15 is also loaded onto smart card 1 00 for use by all venue 
applets. As discussed below, this shared applet pro- 
vides functions commonly available to, and used on 
behalf of, each of the venue applets. 
[0017] Ticket loader 104 loads electronic tickets for 

20 individual events (or a range of events) onto smart card 
100. Each smart card is capable of storing multiple tick- 
ets, for the same or different events, venues, dates, etc. 
Each ticket loaded onto smart card 100 is illustratively 
stored in association with the venue applet correspond- 

25 ing to the venue that is hosting the event and will accept 
the ticket. In a present embodiment, a venue's applet is 
loaded onto smart card 100 (e.g., by applet loader 102) 
before a ticket for an event at that venue is loaded. 
[0018] Ticket validation device 106 is illustratively 

30 located at a venue hosting an event for which a ticket is 
stored on smart card 100. Validation device 106 vali- 
dates the ticket to ensure that it is for a current event 
and accepts the ticket based upon this validation. 
[0019] In a present embodiment of the invention, 

35 applet loader 102, ticket loader 104 and validation 
device 1 06 are separate electronic systems equipped to 
accept, read from, and write to smart card 100. In this 
embodiment, a user physically presents smart card 100 
to each system in order to effect the desired transaction. 

40 In an alternative embodiment, any or all of applet loader 
102, ticket loader 104 and validation device 106 are co- 
located, particularly the applet loader and ticket loader. 
[0020] In yet a further alternative embodiment of the 
invention, any or all of applet loader 102, ticket loader 

45 104 and validation device 106 comprise a computer 
system connected to the Internet or other wide area net- 
work. In such an embodiment, these systems are 
accessed by the user through a user computer system 
that is equipped to accept, read from, and write to smart 

50 card 100. 

[0021] FIG. 2 depicts smart card 100 populated with 
the shared ticketing applet, multiple venue applets, and 
multiple tickets. Smart card 100 incorporates operating 
system 200 to interface with other devices (such as 

55 applet loader 102, ticket loader 104 and validation 
device 106 from FIG. 1) and manage the storage and 
retrieval of information from the smart card. Operating 
system 200 includes, in the illustrated embodiment, a 
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Java Virtual Machine (JVM) for operating loaded 
applets. Operating system 200 further includes crypto- 
graphic key 200a (hereinafter termed the "applet loader 
key") for validating applets loaded onto smart card 100. 
Thus, applet signatures 202b, 210b and 220b are 
authenticated with applet loader key 200a when the 
applets are loaded. Illustratively, applet signatures are 
created prior to, or concurrent with, the loading of the 
associated applet. 

[0022] Shared ticketing applet 202 comprises instruc- 
tions (e.g., in the form of modules, objects, functions, 
etc.) called upon by the various venue applets installed 
on smart card 100. Shared ticketing applet 202 provides 
functions common to each venue applet (e.g., ticket val- 
idation, protocols for communicating with ticket loader 
104 and validation device 106) and therefore allows 
each venue applet to be smaller in size, thus conserving 
storage space on smart card 100. For example, in one 
embodiment of the invention shared ticketing applet 202 
provides instructions for loading a ticket, validating a 
ticket, and/or canceling a ticket (e.g., after it has been 
used to gain admittance to an event). Shared ticketing 
applet 202 includes cryptographic key 202a (hereinafter 
termed the "venue loader key") to validate individual 
venue applets, as described below. In particular, when a 
venue applet is loaded, shared ticketing applet 202 
authenticates each applet's venue signature. 
[0023] In an alternative embodiment of the invention, 
shared ticketing applet comprises instructions for 
enforcing or ensuring adherence to ticket details. For 
example, in such an embodiment smart card 100 could 
be inserted into a smart card reader located within a 
seating area at an event to verify that a user is in his or 
her ticketed seat or to help him or her find the correct 
seat. 

[0024] Venue applets 210, 220 are shown installed on 
smart card 100. Venue applet 210 illustratively repre- 
sents home baseball games of the San Francisco 
Giants. Venue applet 220 illustratively represents 
United Airlines flights. Venue applets 210, 220 include 
cryptographic keys 210a, 220a (hereinafter termed 
"venue keys") that are used to authenticate venue 
applets 210, 220 to ticket loader 104 prior to loading a 
ticket. Venue keys are also used to validate ticket signa- 
tures that accompany tickets for the associated venue. 
[0025] Venue applets 21 0, 220 also include applet sig- 
natures 210b, 220b for validating the venue applets to 
operating system 200. As discussed above, applet sig- 
natures are illustratively created by applet loader 102 
prior to, or concurrent with, the loading of venue applets. 
Operating system 200 then authenticates applet signa- 
tures 210b, 220b with applet loader key 200a when the 
applets are loaded. 

[0026] Venue applets 210, 220 further include venue 
signatures 210c, 220c for validating the venue applets 
to the shared ticketing applet. Similar to applet signa- 
tures 210b, 220b, venue signatures 210c, 220 are cre- 
ated prior to or concurrent with the installation of venue 



applets 210, 220. When the venue applets are loaded, 
shared ticketing applet 202 authenticates the venue sig- 
natures. 

[0027] Tickets 212, 214, 216 represent particular 

5 home ballgames played at the San Francisco Giants 
venue. Ticket 222 represents a particular flight offered 
by United Airlines, from San Francisco to Pittsburgh, PA. 
[0028] Each ticket stored on smart card 100 includes 
information concerning the related event. Thus, tickets 

10 212, 214 and 216 include information such as the date 
of the game, opponent and an assigned seat number. 
The information stored in a ticket is used with the ticket 
signature, in a present embodiment of the invention, to 
validate the authenticity of the ticket. Thus, the amount 

15 and type of information stored with a ticket varies 
depending upon the venue, event, type of ticket, etc. 
Instead of individual tickets 212, 214 and 216, the owner 
of smart card 100 may for example, have just one ticket 
in the form of a season pass. The season pass ticket is 

20 good for more than one date and will therefore include 
information different from tickets 212, 214, 216. 
[0029] Each of tickets 212, 214, 216 and 222 includes 
a ticket signature (represented by the numerals 212a, 
214a, 216a and 222a) generated by ticket loader 104 

25 with a key of the corresponding venue. In an embodi- 
ment of the invention using public key encryption (PKE) 
and asymmetric key pairs, and where venue keys 210a, 
220a are public venue keys, the ticket signatures are 
generated using the private keys corresponding to the 

30 public keys. In an alternative embodiment using sym- 
metric keys (e.g., DES), ticket loader 104 signs issued 
tickets with a copy of venue keys 210a, 220a. As men- 
tioned above, when a ticket is loaded onto smart card 
100, the corresponding venue applet validates the ticket 

35 by authenticating the ticket signature with its venue key 
[0030] One skilled in the art will recognize that an 
applet stored on smart card 1 00 is able to keep data pri- 
vate and thus inaccessible to other stored applets. This 
prevents one applet from corrupting or examining tickets 

40 associated with a particular venue applet. In a present 
embodiment, however, tickets are cancelled or deacti- 
vated after being presented to validation device 106. In 
an alternative embodiment, individual tickets are 
deleted or overwritten. 

45 

Loading an Applet 

[0031] In a present embodiment of the invention, the 
venue applets and the shared ticketing applet that are 
50 loaded onto smart card 100 comprise executable com- 
puter programs or modules of executable computer 
code. In a present embodiment of the invention, the 
shared ticketing applet is substantially identical from 
one smart card to another. Each venue's venue applet is 
55 similarly similar from one smart card to another, except 
for the venue key and any tickets that may be loaded. 
[0032] In one embodiment of the invention, venue 
applets comprise Java applications constructed accord- 
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ing to a standard method. For example, a file containing 
the Java programming instructions is compiled with a 
Java compiler to form a binary class file. The class file is 
then converted into a smart card application file. During 
this conversion process, the card application file is digit- 5 
ally signed using applet loader key 200a (shown in FIG. 
2) or its complement, depending upon the type of cryp- 
tographic encryption (e.g., symmetric or asymmetric). 
[0033] FIG. 3 depicts an illustrative process by which 
a signed card application file (e.g., applet 210 in FIG. 2) 10 
is loaded onto smart card 100 from applet loader 102. 
Applet loader 102 is, in a present embodiment of the 
invention, a ticket vending machine and is co-located 
with ticket loader 104. In this embodiment, venue applet 
210 is automatically loaded when a Giants' baseball 15 
ticket is purchased, unless the applet is already resident 
on smart card 100. Also, in this embodiment shared 
ticketing applet 202 is automatically loaded if not resi- 
dent on smart card 100. In an alternative embodiment, 
either or both of shared ticketing applet 202 and venue 20 
applet 210 are pre-loaded on smart card at the time it is 
manufactured or the time it is sold. 
[0034] With reference now to FIG. 3, state 300 is a 
start state. In state 302, applet loader 102 is coupled to 
smart card 100 and prepares to download applet 210. 25 
Illustratively, the owner of smart card 100 inserts the 
smart card into a device comprising applet loader 102 
and selects applet 210 for installation (e.g., by indicating 
a desire to purchase Giants baseball tickets). In an 
alternative embodiment, the owner inserts smart card 30 
100 into a separate computer system connected to 
applet loader 102 via the Internet or other communica- 
tion link. 

[0035] In state 304, smart card 100 indicates that it is 
prepared to load an applet and, in a present embodi- 35 
ment, passes the applet loader information concerning 
its present configuration (e.g., which applets are loaded, 
which versions of operating system and Java Virtual 
Machine are installed). In one embodiment, smart card 
100 performs a self-check prior to indicating that it is 40 
ready to receive an applet. Illustratively, the self-check 
tests the card's ability to store and retrieve data and 
tests for bad or damaged memory cells. Information 
transmitted to applet loader 1 02 by the smart card may 
include the amount of storage space available on the 45 
card. If insufficient space exists for loading the selected 
applet, an error message is displayed for the user. 
[0036] In state 306, applet loader 102 determines 
whether shared ticketing applet 202 is already resident 
on smart card 100. As described above, shared ticket- so 
ing applet 202 contains instructions used by venue 
applet 210 and other venue applets. Illustratively, this 
determination is made based upon information returned 
to applet loader 102 by smart card 100 in state 304. 
[0037] If it is determined in state 306 that shared tick- 55 
eting applet 202 is not installed on smart card 100, the 
process continues with state 310. Otherwise, in state 
308 it is determined whether venue applet 210 is 



already loaded on smart card 100. If not, the process 
proceeds to state 316. If, however, both applets are 
already loaded, the process exits in end state 320. 
[0038] In state 310 the shared ticketing applet is 
signed (e.g., by applet loader 102), if not already 
signed, with a cryptographic key complementary to 
applet loader key 200a (e.g., when using an asymmetric 
encryption scheme, a "private" key corresponding to 
"public" key 200a) to create applet signature 202b (from 
FIG. 2). The signed applet is then downloaded to smart 
card 100. Illustratively, applets are downloaded and 
stored on the smart card in multiple streams of bytes 
(e.g., approximately 200 bytes in each stream), and 
each stream is validated by an associated checksum. In 
state 312, the smart card validates accurate receipt of 
the applet and, in state 314, informs the applet loader 
whether the installation was successful or not. If shared 
applet 202 could not be correctly loaded, an error mes- 
sage is returned and the process ends at end state 320. 
[0039] If the installation of shared ticketing applet 202 
was successful or, if it was determined in state 308 that 
venue applet 210 has not been loaded, the process 
continues at state 316. 

[0040] In state 31 6, venue applet 21 0 is signed (if not 
already signed) by applet loader 102 to create applet 
signature 210b and/or venue signature 210c and is then 
downloaded onto smart card 100 from applet loader 
102. Venue key 210a, as discussed below, will be used 
to authenticate venue applet 210 to ticket loader 104 
and to validate tickets loaded from the ticket loader. 
Depending upon the type of cryptographic security that 
is preferred (e.g., symmetric or asymmetric keys), 
applet signature 210b and venue signature 210c are 
created with applet loader key 200a and venue loader 
202a, respectively or with their complements. 
[0041] In state 318, smart card 100 validates the 
downloaded applet and indicates to the applet loader 
that it was successfully loaded or that an error was 
encountered. Illustratively smart card 100 validates 
successful receipt of the applet by computing a check- 
sum and comparing it to a checksum provided by applet 
loader 102. In an alternative embodiment, applet signa- 
ture 210b of the downloaded applet is validated using a 
cryptographic technique corresponding to the form of 
the key used to create the signature. In one particular 
such embodiment, smart card 100 computes a hash 
value from the applet and compares it to a hash value 
retrieved from the signature. If they match, the smart 
card considers the applet to have been received intact. 
A similar process is used to validate a ticket signature 
when a ticket is downloaded. The process then ends at 
end state 320. 

Loading a Ticket 

[0042] Once a venue applet is loaded onto smart card 
100, tickets for events at that venue (e.g., matches or 
games at a sporting field, flights offered by an airline) 
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may be purchased and loaded as well. Venue applets, 
shared ticketing applet 202 and related tickets are, in a 
present embodiment of the invention, loaded in con- 
junction with each other, as necessary, from a combined 
ticket/applet loader. 5 
[0043] FIG. 4 depicts an illustrative procedure for pur- 
chasing an electronic ticket to a Giants baseball game 
(for which venue applet 210 has been installed) from 
ticket loader 104 and installing it on smart card 100. In a 
present embodiment of the invention, ticket loader 104 io 
is part of a web server connected to a public network 
such as the Internet. In this embodiment, smart card 
100 is coupled to a computer system operated by the 
owner of smart card 100 that is also connected to the 
Internet. Tickets are selected using an interface for the 15 
venue's web server, and then downloaded over the 
Internet and stored on smart card 100. 
[0044] With reference now to FIG. 4, state 400 is a 
start state. In state 402, the owner of smart card 1 00 ini- 
tiates the ticket purchasing/loading procedure. In one 20 
embodiment of the invention, the owner first selects an 
event for which a ticket is desired. In the presently 
described embodiment, for example, a baseball game is 
identified along with the number and type of seats 
desired. As another example, the owner identifies to an 25 
airline reservation agent a flight the owner wishes to 
take, including a date and time and perhaps a seat. 
After the smart card owner selects his or her 
venue/event and specifies any necessary or criteria 
concerning the event, he or she signals acceptance of 30 
the ticket as configured. 

[0045] In state 404, ticket loader 1 04 identifies itself to 
and challenges smart card 100 in order to authenticate 
the card and/or venue applet 210. Illustratively the chal- 
lenge is a "zero knowledge proof taking the form of a 35 
random number transmitted to smart card 100 by ticket 
loader 104. Venue applet 210 meets the challenge by 
generating a digital signature with venue key 210a, and 
returning the result to ticket loader 1 04. In an alternative 
embodiment, venue applet 210 meets the challenge in 40 
step 406 by encrypting the random number with venue 
key 210a and returning the result to ticket loader 104. 
[0046] In state 408, ticket loader 1 04 validates the sig- 
nature received from smart card 100. For purposes of 
this validation, ticket loader 104 possesses a key com- 45 
plementary to venue key 210a. For example, in an 
embodiment of the invention employing asymmetric 
keys (e.g., RSA), wherein venue key 210a is a public 
key of the associated venue, ticket loader 104 pos- 
sesses the corresponding private key In an embodi- so 
ment of the invention using symmetric keys (e.g.. Digital 
Encryption Standard), ticket loader 104 and venue 
applet 21 0 possess copies of the same key If the valida- 
tion attempt fails, the ticket loading process either 
attempts the challenge/validation procedure again (up 55 
to a limited number of times) or fails and reports an 
error, depending upon the implementation and security 
concerns. 



[0047] Next, in state 410 ticket loader 104 generates 
and signs ticket 212 for the venue based upon the event 
data selected by the smart card owner/user. Illustra- 
tively, ticket loader 104 signs ticket 212 using the same 
key with which venue applet 210 was validated in state 
408. In state 412, ticket 212, complete with signature 
212a, is downloaded and stored on smart card 100. 
[0048] In state 414, venue applet 210 validates down- 
loaded ticket 212 by authenticating signature 212a with 
venue key 210a and responds, in state 41 6, with a mes- 
sage indicating success or failure. In an alternative 
embodiment of the invention, a second venue key, dif- 
ferent from venue key 210a is stored with venue applet 
210 for the purpose of validating downloaded tickets. 
The procedure ends with end state 418. 
[0049] In the presently described embodiment, the 
process described above must be followed for each 
ticket downloaded from ticket loader 104. In an alterna- 
tive embodiment, multiple tickets may be selected, proc- 
essed and downloaded for a single venue at a time. 

Validating a Ticket 

[0050] In a present embodiment of the invention, tick- 
ets are validated by validation device 106 when pre- 
sented for acceptance at the appropriate venue. FIG. 5 
depicts an illustrative procedure for validating ticket 212 
in accordance with a present embodiment of the inven- 
tion. 

[0051] State 500 is a start state. In state 502, a user 
presents smart card 100 to validation device 106 in 
order to gain admittance to the ball game identified in 
ticket 212. Illustratively validation device 106 comprises 
a computer system configured to accept and communi- 
cate with smart card 100. 

[0052] In state 504, validation device 106 generates 
and issues a challenge to smart card 1 00 as was done 
in the ticket loading procedure described above. The 
random number provided to smart card 1 00 is signed by 
venue applet 210, using venue key 210a, in state 506. In 
state 508, the validation device authenticates the signa- 
ture using a key complementary to venue key 210a. By 
authenticating the signature returned with the chal- 
lenge, validation device 106 is able to validate venue 
applet 210. 

[0053] After authenticating the signature, in state 510 
validation device 106 requests ticket data retained by 
smart card 100. Venue applet 210 transmits ticket 212 
(e.g., the ticket data and signature) to validation device 
106 in state 512. Illustratively validation device 106 is 
only informed of stored ticket(s) usable for a current 
event, which are identified by the date, time and/or other 
identifying data. In one embodiment of the invention, 
shared ticketing applet 202 determines the ticket(s) to 
be identified to validation device 106 (e.g., by determin- 
ing which venue - and therefore which venue applet and 
tickets - corresponds to the validation device). Alterna- 
tively venue applet 210 and validation device 106 com- 
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municate in order to determine whicli, of multiple tickets 
associated witli the present venue, sliould be used. 
[0054] In state 514, validation device 1 06 verifies the 
ticket data (e.g., confirms the date, time, participating 
teams, seat number) and authenticates the ticket signa- 
ture. If the ticket data and signature pass inspection, 
smart card 100 is instructed to cancel or erase ticket 
212 and the user is admitted. 

[0055] In the presently described embodiment of the 
invention, ticket 212 will be overwritten with a future 
ticket loaded onto smart card 100. In an alternative 
embodiment, tickets are not erased or overwritten. 
[0056] The foregoing descriptions of embodiments of 
the invention have been presented for purposes of illus- 
tration and description only. They are not intended to be 
exhaustive or to limit the invention to the forms dis- 
closed. Many modifications and variations will be appar- 
ent to practitioners skilled in the art. Accordingly the 
above disclosure is not intended to limit the invention; 
the scope of the invention is defined by the appended 
claims. 

Claims 

1. A method of using an electronic device (100) to 
store tickets, comprising: 

receiving a first venue module (21 0) associated 
with a first venue, said first venue module 
including a first venue key (210a) for validating 
tickets for said first venue; 
validating said first venue module with a mod- 
ule loader key (200a) of the electronic device; 
receiving a first ticket (212) for an event offered 
at said first venue; 

receiving a first ticket signature (212a) associ- 
ated with said first ticket; and 
authenticating (414) said first ticket signature 
with said first venue key (210a). 

2. The method of claim 1 , further comprising the step 
of 

providing said first ticket to a validation device 
(106) of said first venue. 

3. The method of claim 1 or claim 2, further compris- 
ing: 

storing a second venue module (220), wherein 
said second venue module is associated with a 
second venue and includes a second venue 
key (220a); 

wherein said second venue is different from 
said first venue. 

4. The method of any one of claims 1 to 3 , further 
comprising: 



receiving a second electronic ticket (222) for 
admission to an event at said second venue; 
receiving a second ticket signature (222a), said 
second ticket signature being associated with 
5 said second electronic ticket; and 

authenticating said second ticket signature with 
said second venue key (220a). 

5. The method of any one of claims 1 to 4, further 
10 comprising: 

determining (306) whether a shared module 
(202) is stored on the electronic device (100); 
and 

15 receiving (310) said shared module if said 

shared module is not stored on the electronic 
device. 

6. The method of claim 5, wherein said shared module 
20 (202) has a shared venue key for validating said 

first venue module, and optionally comprising the 
further step of 

validating said shared module with said module 
25 loader key (200a). 

7. The method of claim 5 or claim 6, wherein each of 
said first venue module (21 0) and said shared mod- 
ule (262) include a module signature and wherein 

30 said validating comprises authenticating the mod- 
ule signature of the validated module with the mod- 
ule loader key (200a). 

8. The method of any one of claims 5 to 7, wherein 
35 said receiving a shared module (202) comprises: 

receiving a second series of instructions used 
by one or more venue modules; 
receiving a venue loader key (202a) for validat- 
40 ing said one or more venue modules; 

storing said second series of instructions; and 
storing said venue loader key (202a) in associ- 
ation with said second series of instructions. 

45 9. The method of any one of claims 1 to 7, wherein 
receiving a first ticket (212) comprises: 

receiving (404) a challenge from a ticket loader 
(104); 

50 signing (406) said challenge with said first 

venue key (210a); and 

transmitting said signed challenge to said ticket 
loader. 

55 10. The method of any one of claims 1 to 9, wherein 
receiving a first venue module (210) comprises: 

receiving (316) a first series of instructions for 
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processing a ticket for an event at a first venue; 
receiving a first venue key (210a) for said first 
venue; 

storing said series of instructions; and 

storing said first venue key in association with s 

said series of instructions. 

11. The method of anyone of claims 1 to 10, wherein 
said validating comprises authenticating a module 
signature of said first venue module with a module io 
loader key of the electronic device. 

12. The method of anyone of claims 1 to 11, further 
comprising cancelling (514) said first ticket (212), 
which preferably comprises marking said first ticket 15 
invalid. 

13. The method of anyone of claims 1 to 12, further 
comprising: 

20 

marking said shared module invalid; and 
receiving a new version of said shared module. 

14. The method of claim 9, wherein receiving a chal- 
lenge comprises receiving a randomly generated 25 
number. 

15. The method of anyone of claims 1 to 14, wherein 
receiving a first electronic ticket comprises receiv- 
ing one or more details of an event at said first 30 
venue. 

16. A method of tendering a ticket, said ticket being 
stored on an electronic device capable of storing 
tickets for multiple venues, comprising: 35 

receiving (504) a challenge from a validation 
device (106) at a venue; 
signing (506) said challenge using a first venue 
key (210a); 40 
transmitting (508) said signed challenge to said 
validation device; 

receiving (502) a request for a first ticket to an 
event at said venue; and 

transmitting (51 2) said first ticket. 45 

17. The method of claim 16, further comprising cancel- 
ling (514) said first ticket. 

18. The method of any one of claim 16 or 17, wherein so 
receiving a challenge comprises receiving a ran- 
domly generated number. 

19. The method of any one of claims 16 to 18, wherein 
transmitting (512) said first ticket (212) comprises 55 
transmitting one or more details comprising said 
first ticket to said event. 



20. A ticket storing apparatus (1 00) comprising a mem- 
ory device for storing: 

a first venue module (210) for processing a 
ticket to an event at a first venue; 
a device key (200a) for validating said first 
venue module; 

a first ticket (212) to said event, said ticket hav- 
ing a ticket signature (212a); 
a venue key (210a) for authenticating said 
ticket signature; and 

an interface module (202) for interfacing said 
first venue module with one of a ticket loader 
and a validation device, said interface module 
being shareable among a plurality of venue 
modules. 

21. The apparatus of claim 20, further comprising a 
second venue module (220) for processing a ticket 
to an event at a second venue. 

22. The apparatus of any one of claims 20 to 21, 
wherein the ticket storing apparatus comprises a 
smart card or a hand-held computer. 

23. A data structure contained in a computer readable 
storage medium for storing a ticket, said data struc- 
ture comprising: 

a first venue module (210) for processing a 
ticket to an event at a first venue; 
a device key (210a) for validating said first 
venue module; 

a first ticket (212) to said event, said ticket hav- 
ing a ticket signature (212a); 
a venue key for authenticating said ticket signa- 
ture; and 

an interface module for interfacing said first 
venue module with one of a ticket loader and a 
validation device, said interface module being 
shareable among a plurality of venue modules. 

24. An apparatus (1 06) for processing tickets for events 
at multiple venues, comprising: 

receiving means (100) for receiving a module, 
said module comprising a series of instructions 
for processing a ticket from an applet loader; 
module validation means ( 300: 320) for vali- 
dating said series of instructions; 
ticket receiving means ( 400: 41 2) for receiving 
a ticket from a ticket loader; 
ticket validation means (414) for validating said 
ticket; and 

transmission means ( 502)fbr transmitting said 
ticket to a validation device. 

25. A computer readable storage medium ( 1 00) storing 
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instructions that, when executed by a computer, 
cause the computer to perform a method for 
processing an electronic ticket, the method com- 
prising; 

receiving ( 300:316) a first venue module asso- 
ciated with a first venue, said first venue mod- 
ule including a first venue key for validating 
tickets for said first venue; 
validating ( 318) said first venue module with a 
module loader key of the electronic storage 
device; 

receiving ( 400: 404) a first ticket for an event 
offered at said first venue; 
receiving ( 406) a first ticket signature with said 
first ticket; 

authenticating ( 408) said first ticket signature 
with said first venue key; and 
providing ( 500:518) said first ticket to a valida- 
tion device of said first venue. 

26. A computer program encoding a set of computer 
instructions for using an electronic device to store 
and tender tickets, which when running on a com- 
puter is adapted to perform the method as claimed 25 
in any one of claims 1 to 19. 
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